Desktop publishing software programs for personal computers have been available for a number of years. These desktop publishing software programs typically include a number of predefined or "canned" layouts that the desktop publishing software program can render based on specifications received from a user through a high-level interface known as a "wizard." For example, a first predefined layout may be used to create newsletters, a second predefined layout may be used to create sales fliers, a third predefined layout may be used to create wedding invitations, and so forth.
To create a desktop publishing document, the author of the document may select one of the predefined layouts. The wizard then displays a menu-driven utility for the selected layout. The author selects among the options offered by the menu-driven utility to specify the parameters of the layout. Upon receiving an acceptance command from the author, the wizard renders a generic version of the document in accordance with the layout parameters specified through the menu-driven utility. The author may then enter content into the document. The author may also add, delete, and alter the format of the various visible objects of the document. For example, the author may add pictures to the document, change the font of text entries, add headings and footers, and so forth.
The document created by the author with the assistance of the wizard is typically composed of a number of objects. Each object corresponds to a visible element of the document. For a newsletter example, a first object corresponds to the masthead of the newsletter, a second object corresponds to the headline for an article, a third object corresponds to the body of the article, a fourth object corresponds to a picture within the article, a fifth object corresponds to a vertical double-line section divider between the columns of the article, and so forth. Each object includes a number of object properties that define the visible appearance of the object. For example, a first object property specifies the position of the object, a second object property specifies the content of the object, such as text, a third object property specifies the font of the text, a fourth object property specifies the size of the text, and so forth. In this manner, the content and appearance of the document are defined by the object properties of the objects within the document.
After the wizard renders the generic version of the document, the author typically edits and enters content into the layout one object at a time to complete the document. Although the author may want to apply the same format to a number of objects, the author must typically apply the format to each object individually. For example, the user may want to change the font for the headlines in a newsletter that includes several headlines. To do so, the author must change the font for each headline one at a time. Having to perform the same editorial operation for each headline can be tedious and time consuming.
Tedious repetition of editorial changes can also occur with respect to the content of certain objects. For example, the author of a sales flier typically wants identical tear-away tabs along the bottom of the flier. To create the tear-away tabs, the author defines the content for one tab and copies the content to the other tabs. If the author later changes the content of the tear-away tabs, the author must once again define the content for one of the tear-away tabs and then copy the content to the other tabs. Having to copy the content to the other tabs for each change can be tedious and time consuming.
For many predefined layouts, these repetitious editorial changes are often unnecessary. This is because the author of a document using a particular predefined layout almost always wants the format or content of certain groups of objects to be the same. Moreover, the appropriate object property links for a particular layout can usually be ascertained in advance based solely on the intended purpose of the layout. For example, the author of a newsletter almost always wants the same font for all of the headlines. Similarly, the author of a sales flier almost always wants the same content for all of the tear-away tabs that extend along the bottom of the flier.
Linking object properties that define the format and content of a desktop publishing document is complicated by the development environment for typical desktop publishing software programs. In this development environment, the basic desktop publishing software program is typically released with a minimal number of predefined layouts. Additional predefined layouts may be developed by individual software developers using a Software Developer's Kit (SDK) on a layout-by-layout basis. For this reason, the developers of the basic program cannot know what type of object property links will be appropriate for layouts that are developed after release of the basic program.
Prior art desktop publishing software programs typically work with a registry that automatically propagates global parameters, such as the owner's name and business address, to multiple programs and files on the computer system. Because the developers of a basic desktop publishing software program cannot know what type of object property propagation rules will be appropriate for layouts that are developed after release of the basic program, prior art registries are not configured to define different propagation rules for different desktop publishing documents. For this reason, prior art registry systems cannot be used to define object property propagation rules for a variety of predefined layouts for a desktop publishing software program.
Thus, there is a need in the art for a method and system for propagating object properties in a desktop publishing software program. There is a further need for a desktop publishing software program that includes object property propagation rules for a variety of predefined layouts for desktop publishing documents.